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I. REAL PARTY IN INTEREST 

The real party in interest is International Business Machines Corporation, 
Armonk, New York, assignee of 100% interest of the above-referenced patent 
application. 

II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals or interferences known to Appellants, Appellants' legal 
representative or Assignee which would directly affect or be directly affected by or have 
a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

Claims 1-26 are all the claims pending in the application and are set forth fully in 
the attached appendix (Section IX), are under appeal. Claims 1-26 were originally filed 
in the application on September 9, 2003. A non-final Office Action was issued on June 
29, 2006 rejecting claims 1-26. The Appellants filed an Amendent under 37 C.F.R. 
§1.111 on July 31, 2006 amending claims 1-2,5,7-8, 11, 13-15, 19-21, 24 and 26. A 
final Office Action was issued on October 18, 2006 rejecting claims 1-26. The 
Appellants filed an Amendent under 37 C.F.R. §1.1 16 on December 12, 2006, amending 
claims 1-2, 5, 7-8, 11, 13-15, 19-21, 24, and 26. An Advisory Action was issued on 
January 12, 2007 indicating that the Amendent filed under 37 C.F.R. §1.116 on 
December 12, 2006 would not be entered. The Appellants filed a request for continued 
examination (RCE) on January 18, 2007 to force entry of the December 12, 2006 
amendment. A non-final Office Action was issued on April 17, 2007, rejecting claims 1- 
26. The Appellants filed a Notice of Appeal on April 30, 2007. 

Claims 1-26 stand rejected under 35 U.S.C. §101, as being directed to non- 
statutory subject matter. Claims 1-26 further stand rejected under 35 U.S.C. § 1 12, first 
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paragraph, in light of the 35 U.S.C. §101 rejection. Appellants respectfully traverse these 
rejections based on the following discussion. 

IV. STATEMENT OF AMENDMENTS 

A non-final Office Action, dated April 17, 2007, stated that claims 1-26, all the 
claims presently pending in the application, were rejected. Claims 1-26 shown in the 
appendix (Section IX) are in their amended form as submitted in the December 12, 2006 
amendment and entered in response to the January 18, 2007 request for continued 
examination (RCE). 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The Appellants' claimed invention is described on pages 1 through 5 of the 
specification and illustrated in Figures 1 through 5 of the application, as originally filed 
and published in U.S. Patent Application Publication No. 2005/028351 1. It should be 
noted that in the following discussion all references to specific paragraph numbers are 
directed to the U.S. Patent Application Publication document. More specifically: 

Claim 1 is for a method of automatically identifying anomalous situations during 
system operations. One feature of the invention as claimed in claim 1 is recording 
features of normal system operations in a history file. Claim 1 defines this feature as 
follows: "recording features of normal system operations in a history file". This feature 
is described at various points in the specification. For example, paragraphs [0006] and 
[0023] describe this feature as follows: "The invention begins with historical data 100 
(possibly maintain in a history file)". Paragraph [0021] describes this feature as follows: 
"Assuming there is a dataset of N features." Paragraph [0024] describes this feature as 
"features 102 from normal computerized system operations (from the history file)." This 
feature is shown as item 100 in Figure 1. 

Another feature of the invention as claimed in claim 1 is automatically creating a 
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model for each of the feature of the normal system operations in said history file. Claim 
1 defines this feature as follows: "automatically creating a model for each of said features 
of said normal system operations in said history file". This feature is described at various 
points in the specification. For example, paragraphs [0006] and [0023] describe this 
feature as "The invention then automatically creates a model fore each feature only from 
normal data in the history file." Paragraph [0021] describes this feature as follows: "In 
order to detect anomalies, the invention converts the problem into N modes. Each model 
is a function to map N-l features to I remaining features...". Paragraph [0024] further 
describes the details of the creating process. This feature is shown as items 102-110 in 
Figure 1. 

Another feature of the invention as claimed in claim 1 is calculating anomaly 
scores of the features of the normal system operations and storing the anomaly scores in a 
trained file. Claim 1 defines this feature as follows: "calculating anomaly scores of said 
features of said normal system operations and storing said anomaly scores in a trained 
file". This feature is described at various points in the specification. For example, 
paragraphs [0008] and [0025] provide: "After so creating the model, the invention then 
performs training by calculating anomaly scores of the features. More specifically, the 
invention predicts the likelihood that each feature will be normal, when one or more of 
the other features are abnormal, using the models. This process is repeated using different 
presumptions about other features being normal and abnormal to produce a trained file of 
a plurality of normality and anomaly scores for each of the features. The trained file thus 
provides an anomaly score for each of the features for each of a plurality of different 
possible abnormalities." This feature is shown as item 1 12 in Figure 1. 

Another feature of the invention as claimed in claim 1 is establishing a threshold 
to evaluate whether events in live system operations are anomalies as compare to the 
normal system operations. Claim 1 defines this feature as follows: "establishing a 
threshold to evaluate whether events in live system operations are anomalies as compare 
to said normal system operations". This feature is described at various points in the 
specification. For example, paragraph [0026] describes this feature as follows: "The 
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invention also establishes a threshold 116 to evaluate whether features are abnormal". 
This feature is shown as item 1 14 in Figure 1. 

Another feature of the invention as claimed in claim 1 is automatically identifying 
anomalous events in the live system operations based on the anomaly scores and on the 
threshold. Claim 1 defines this feature as follows: "automatically identifying anomalous 
events in said live system operations based on said anomaly scores and on said 
threshold". This feature is described at various points in the specification. For example, 
paragraph [0024] describes this feature as follows: "The invention automatically 
identifies abnormal actions of the computerized system based on the anomaly scores and 
the threshold. More specifically, the invention determines the "true" values of the 
features for a given live operation of the computerized system 118. With this 
information, the invention refers to the trained file to retrieve an anomaly score for each 
of the features and then compares the anomaly score for each of the features with the 
threshold to determine whether each anomaly score exceeds the threshold". This feature 
is shown as items 1 16-1 18 in Figure 1. 

Another feature of the invention as claimed in claim 1 is reporting the anomalous 
events. Claim 1 defines this feature as follows: "reporting said anomalous events." This 
feature is described at various points in the specification. For example, paragraph [0063] 
describes this feature as follows: "When an abnormal state happens, the inter-feature 
model will capture their differences from normal state and report the problem to the user 
of the system". This is shown in Figure 4. 

Another feature of the invention as claimed in claim 1 is periodically repeating 
the calculating. Claim 1 defines this feature as follows: "periodically repeating said 
calculating." This feature is described at various points in the specification. For 
example, as discussed above paragraphs [0008] and [0023] provide" "After so creating 
the model, the invention then performs training by calculating anomaly scores of the 
features. More specifically, the invention predicts the likelihood that each feature will be 
normal, when one or more of the other features are abnormal, using the models. This 
process is repeated using different presumptions about other features being normal and 
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abnormal to produce a trained file of a plurality of normality and anomaly scores for each 
of the features. The trained file thus provides an anomaly score for each of the features 
for each of a plurality of different possible abnormalities." These paragraphs further 
provide: "The training process 112 [i.e., the process of calculating anomaly scores of said 
features of said normal system operations] can be periodically repeated." This is shown 
in Figure 1. 

Claim 8 is similarly for a method of automatically identifying anomalous 
situations during system operations. One feature of the invention as claimed in claim 8 is 
recording features of normal system operations in a history file. Claim 1 defines this 
feature as follows: "recording features of normal system operations in a history file". 
This feature is described at various points in the specification. For example, paragraphs 
[0006] and [0023] describe this feature as follows: "The invention begins with historical 
data 100 (possibly maintain in a history file)". Paragraph [0021] describes this feature as 
follows: "Assuming there is a dataset of N features." Paragraph [0024] describes this 
feature as "features 102 from normal computerized system operations (from the history 
file)." This feature is shown as item 100 in Figure 1. 

Another feature of the invention as claimed in claim 8 is automatically creating a 
model for each of the feature of the normal system operations in said history file. Claim 
8 defines this feature as follows: "automatically creating a model for each of said features 
of said normal system operations in said history file". This feature is described at various 
points in the specification. For example, paragraphs [0006] and [0023] describe this 
feature as "The invention then automatically creates a model fore each feature only from 
normal data in the history file." Paragraph [0021] describes this feature as follows: "In 
order to detect anomalies, the invention converts the problem into N modes. Each model 
is a function to map N-l features to I remaining features. . .". Paragraph [0024] further 
describes the details of the creating process. This feature is shown as items 102-110 in 
Figure 1. 

This feature of automatically creating said model in claim 8 is further defined by 
claim 8 as comprising the following features: (1) establishing relationships that exist 
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between each of said features for said normal system operations; (2) selecting a labeled 
feature from said features; (3) mathematically rearranging said relationships from the 
point of view of said labeled feature to create a solution for said labeled feature, wherein 
said solution comprises a model for said labeled feature; (4) selecting different features as 
said labeled feature and (5) repeating said process of mathematically rearranging said 
relationships to produce solutions from the point of view of each remaining feature as 
models for the remaining features. Each of these features is described at various points 
in the specification. For example, each of these features is disclosed in paragraph [0024] 
which provides: "More specifically, in order to create the models for the features, the 
invention establishes relationships that exist between the features 102 for normal 
computerized system operations (from the history file). Then the invention selects a 
lab led feature 104 from the features and mathematically rearranges the relationships 106 
from the point of view of the labeled feature to create a solution for the labeled feature. 
This "solution is the model for that labeled feature. The solution comprises a 
mathematical statement of what the labeled feature equals in terms of the relationships 
between the remaining features. The invention checks whether there are any more 
features that need to be modeled 108. If so, the invention selects a different feature as the 
labeled feature 1 10 and repeats the process (shown by the loop in FIG. 1) of 
mathematically rearranging the relationships to produce solutions from the point of view 
of each remaining feature (as models for those remaining features)." 

Another feature of the invention as claimed in claim 8 is calculating anomaly 
scores of the features of the normal system operations and storing the anomaly scores in a 
trained file. Claim 8 defines this feature as follows: "calculating anomaly scores of said 
features of said normal system operations and storing said anomaly scores in a trained 
file". This feature is described at various points in the specification. For example, 
paragraphs [0008] and [0025] provide: "After so creating the model, the invention then 
performs training by calculating anomaly scores of the features. More specifically, the 
invention predicts the likelihood that each feature will be normal, when one or more of 
the other features are abnormal, using the models. This process is repeated using different 
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presumptions about other features being normal and abnormal to produce a trained file of 
a plurality of normality and anomaly scores for each of the features. The trained file thus 
provides an anomaly score for each of the features for each of a plurality of different 
possible abnormalities." This feature is shown as item 112 in Figure 1. 

Another feature of the invention as claimed in claim 8 is establishing a threshold 
to evaluate whether events in live system operations are anomalies as compare to the 
normal system operations. Claim 8 defines this feature as follows: "establishing a 
threshold to evaluate whether events in live system operations are anomalies as compare 
to said normal system operations". This feature is described at various points in the 
specification. For example, paragraph [0026] describes this feature as follows: "The 
invention also establishes a threshold 1 16 to evaluate whether features are abnormal". 
This feature is shown as item 1 14 in Figure 1 . 

Another feature of the invention as claimed in claim 8 is automatically identifying 
anomalous events in the live system operations based on the anomaly scores and on the 
threshold. Claim 8 defines this feature as follows: "automatically identifying anomalous 
events in said live system operations based on said anomaly scores and on said 
threshold". This feature is described at various points in the specification. For example, 
paragraph [0024] describes this feature as follows: "The invention automatically 
identifies abnormal actions of the computerized system based on the anomaly scores and 
the threshold. More specifically, the invention determines the "true" values of the 
features for a given live operation of the computerized system 118. With this 
information, the invention refers to the trained file to retrieve an anomaly score for each 
of the features and then compares the anomaly score for each of the features with the 
threshold to determine whether each anomaly score exceeds the threshold". This feature 
is shown as items 116-118 in Figure 1. 

Another feature of the invention as claimed in claim 8 is reporting the anomalous 
events. Claim 8 defines this feature as follows: "reporting said anomalous events." This 
feature is described at various points in the specification. For example, paragraph [0063] 
describes this feature as follows: "When an abnormal state happens, the inter-feature 
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model will capture their differences from normal state and report the problem to the user 
of the system". This is shown in Figure 4. 

Another feature of the invention as claimed in claim 8 is periodically repeating 
the calculating. Claim 8 defines this feature as follows: "periodically repeating said 
calculating." This feature is described at various points in the specification. For 
example, as discussed above paragraphs [0008] and [0023] provide" "After so creating 
the model, the invention then performs training by calculating anomaly scores of the 
features. More specifically, the invention predicts the likelihood that each feature will be 
normal, when one or more of the other features are abnormal, using the models. This 
process is repeated using different presumptions about other features being normal and 
abnormal to produce a trained file of a plurality of normality and anomaly scores for each 
of the features. The trained file thus provides an anomaly score for each of the features 
for each of a plurality of different possible abnormalities." These paragraphs further 
provide: "The training process 1 12 [i.e., the process of calculating anomaly scores of said 
features of said normal system operations] can be periodically repeated." This is shown 
in Figure 1. 

Claim 14 is similarly for a method of automatically identifying anomalous 
situations during system operations. One feature of the invention as claimed in claim 14 
is recording features of normal system operations in a history file. Claim 41 defines this 
feature as follows: "recording features of normal system operations in a history file". 
This feature is described at various points in the specification. For example, paragraphs 
[0006] and [0023] describe this feature as follows: "The invention begins with historical 
data 100 (possibly maintain in a history file)". Paragraph [0021] describes this feature as 
follows: "Assuming there is a dataset of N features." Paragraph [0024] describes this 
feature as "features 102 from normal computerized system operations (from the history 
file)." This feature is shown as item 100 in Figure 1. 

Another feature of the invention as claimed in claim 14 is automatically creating a 
model for each of the feature of the normal system operations in said history file. Claim 
14 defines this feature as follows: "automatically creating a model for each of said 
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features of said normal system operations in said history file". This feature is described 
at various points in the specification. For example, paragraphs [0006] and [0023] 
describe this feature as "The invention then automatically creates a model fore each 
feature only from normal data in the history file." Paragraph [0021] describes this feature 
as follows: "In order to detect anomalies, the invention converts the problem into N 
modes. Each model is a function to map N-l features to I remaining features. . .". 
Paragraph [0024] further describes the details of the creating process. This feature is 
shown as items 102-110 in Figure 1. 

Another feature of the invention as claimed in claim 14 is calculating anomaly 
scores of the features of the normal system operations and storing the anomaly scores in a 
trained file. Claim 14 defines this feature as follows: "calculating anomaly scores of said 
features of said normal system operations and storing said anomaly scores in a trained 
file". This feature is described at various points in the specification. For example, 
paragraphs [0008] and [0025] provide: "After so creating the model, the invention then 
performs training by calculating anomaly scores of the features. More specifically, the 
invention predicts the likelihood that each feature will be normal, when one or more of 
the other features are abnormal, using the models. This process is repeated using different 
presumptions about other features being normal and abnormal to produce a trained file of 
a plurality of normality and anomaly scores for each of the features. The trained file thus 
provides an anomaly score for each of the features for each of a plurality of different 
possible abnormalities." This feature is shown as item 1 12 in Figure 1. 

This calculating feature in claim 14 is further defined as comprising the features 
of (1) "predicting a likelihood that each feature will be normal when one or more of the 
other features are abnormal, using said model of each of said features" and (2) "repeating 
said predicting using different presumptions about other features being normal and 
abnormal to produce said trained file of a plurality of anomaly scores for each of said 
features." Each of these features is described at various points in the specification. For 
example, paragraph [0025] provides: "After so creating the models, the invention then 
performs training 112 by calculating anomaly scores of the features. More specifically, 
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the invention predicts the likelihood that each feature will be normal, when one or more 
of the other features are abnormal, using the models. This process is repeated using 
different presumptions about other features being normal and abnormal to produce a 
trained file of a plurality of normality and anomaly scores for each of the features. The 
trained file thus provides an anomaly score for each of the features for each of a plurality 
of different possible abnormalities." 

Another feature of the invention as claimed in claim 14 is establishing a threshold 
to evaluate whether events in live system operations are anomalies as compare to the 
normal system operations. Claim 14 defines this feature as follows: "establishing a 
threshold to evaluate whether events in live system operations are anomalies as compare 
to said normal system operations". This feature is described at various points in the 
specification. For example, paragraph [0026] describes this feature as follows: "The 
invention also establishes a threshold 1 16 to evaluate whether features are abnormal". 
This feature is shown as item 1 14 in Figure 1. 

Another feature of the invention as claimed in claim 14 is automatically 
identifying anomalous events in the live system operations based on the anomaly scores 
and on the threshold. Claim 14 defines this feature as follows: "automatically identifying 
anomalous events in said live system operations based on said anomaly scores and on 
said threshold". This feature is described at various points in the specification. For 
example, paragraph [0024] describes this feature as follows: "The invention 
automatically identifies abnormal actions of the computerized system based on the 
anomaly scores and the threshold. More specifically, the invention determines the "true" 
values of the features for a given live operation of the computerized system 118. With 
this information, the invention refers to the trained file to retrieve an anomaly score for 
each of the features and then compares the anomaly score for each of the features with 
the threshold to determine whether each anomaly score exceeds the threshold". This 
feature is shown as items 116-118 in Figure 1. 

Another feature of the invention as claimed in claim 14 is reporting the 
anomalous events. Claim 14 defines this feature as follows: "reporting said anomalous 
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events." This feature is described at various points in the specification. For example, 
paragraph [0063] describes this feature as follows: "When an abnormal state happens, the 
inter-feature model will capture their differences from normal state and report the 
problem to the user of the system". This is shown in Figure 4. 

Another feature of the invention as claimed in claim 14 is periodically repeating 
the calculating. Claim 14 defines this feature as follows: "periodically repeating said 
calculating." This feature is described at various points in the specification. For 
example, as discussed above paragraphs [0008] and [0023] provide" "After so creating 
the model, the invention then performs training by calculating anomaly scores of the 
features. More specifically, the invention predicts the likelihood that each feature will be 
normal, when one or more of the other features are abnormal, using the models. This 
process is repeated using different presumptions about other features being normal and 
abnormal to produce a trained file of a plurality of normality and anomaly scores for each 
of the features. The trained file thus provides an anomaly score for each of the features 
for each of a plurality of different possible abnormalities." These paragraphs further 
provide: "The training process 112 [i.e., the process of calculating anomaly scores of said 
features of said normal system operations] can be periodically repeated." This is shown 
in Figure 1 . 

Claim 20 is for a program storage device readable by machine, tangibly 
embodying a program of instructions executable by the machine to perform for a method 
of automatically identifying anomalous situations during system operations. One feature 
of the invention as claimed in claim 20 is recording features of normal system operations 
in a history file. Claim 20 defines this feature as follows: "recording features of normal 
system operations in a history file". This feature is described at various points in the 
specification. For example, paragraphs [0006] and [0023] describe this feature as 
follows: "The invention begins with historical data 100 (possibly maintain in a history 
file)". Paragraph [0021] describes this feature as follows: "Assuming there is a dataset of 
N features." Paragraph [0024] describes this feature as "features 102 from normal 
computerized system operations (from the history file)." This feature is shown as item 
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100 in Figure 1. 

Another feature of the invention as claimed in claim 20 is automatically creating a 
model for each of the feature of the normal system operations in said history file. Claim 
20 defines this feature as follows: "automatically creating a model for each of said 
features of said normal system operations in said history file". This feature is described 
at various points in the specification. For example, paragraphs [0006] and [0023] 
describe this feature as "The invention then automatically creates a model fore each 
feature only from normal data in the history file." Paragraph [0021] describes this feature 
as follows: "In order to detect anomalies, the invention converts the problem into N 
modes. Each model is a function to map N-l features to I remaining features. . .". 
Paragraph [0024] further describes the details of the creating process. This feature is 
shown as items 102-110 in Figure 1. 

Another feature of the invention as claimed in claim 20 is calculating anomaly 
scores of the features of the normal system operations and storing the anomaly scores in a 
trained file. Claim 20 defines this feature as follows: "calculating anomaly scores of said 
features of said normal system operations and storing said anomaly scores in a trained 
file". This feature is described at various points in the specification. For example, 
paragraphs [0008] and [0025] provide: "After so creating the model, the invention then 
performs training by calculating anomaly scores of the features. More specifically, the 
invention predicts the likelihood that each feature will be normal, when one or more of 
the other features are abnormal, using the models. This process is repeated using different 
presumptions about other features being normal and abnormal to produce a trained file of 
a plurality of normality and anomaly scores for each of the features. The trained file thus 
provides an anomaly score for each of the features for each of a plurality of different 
possible abnormalities." This feature is shown as item 1 12 in Figure 1. 

Another feature of the invention as claimed in claim 20 is establishing a threshold 
to evaluate whether events in live system operations are anomalies as compare to the 
normal system operations. Claim 20 defines this feature as follows: "establishing a 
threshold to evaluate whether events in live system operations are anomalies as compare 
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to said normal system operations". This feature is described at various points in the 
specification. For example, paragraph [0026] describes this feature as follows: "The 
invention also establishes a threshold 116 to evaluate whether features are abnormal". 
This feature is shown as item 1 14 in Figure 1. 

Another feature of the invention as claimed in claim 20 is automatically 
identifying anomalous events in the live system operations based on the anomaly scores 
and on the threshold. Claim 20 defines this feature as follows: "automatically identifying 
anomalous events in said live system operations based on said anomaly scores and on 
said threshold". This feature is described at various points in the specification. For 
example, paragraph [0024] describes this feature as follows: "The invention 
automatically identifies abnormal actions of the computerized system based on the 
anomaly scores and the threshold. More specifically, the invention determines the "true" 
values of the features for a given live operation of the computerized system 118. With 
this information, the invention refers to the trained file to retrieve an anomaly score for 
each of the features and then compares the anomaly score for each of the features with 
the threshold to determine whether each anomaly score exceeds the threshold". This 
feature is shown as items 1 16-1 18 in Figure 1. 

Another feature of the invention as claimed in claim 20 is reporting the 
anomalous events. Claim 20 defines this feature as follows: "reporting said anomalous 
events." This feature is described at various points in the specification. For example, 
paragraph [0063] describes this feature as follows: "When an abnormal state happens, the 
inter-feature model will capture their differences from normal state and report the 
problem to the user of the system". This is shown in Figure 4. 

Another feature of the invention as claimed in claim 20 is periodically repeating 
the calculating. Claim 20 defines this feature as follows: "periodically repeating said 
calculating." This feature is described at various points in the specification. For 
example, as discussed above paragraphs [0008] and [0023] provide" "After so creating 
the model, the invention then performs training by calculating anomaly scores of the 
features. More specifically, the invention predicts the likelihood that each feature will be 
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normal, when one or more of the other features are abnormal, using the models. This 
process is repeated using different presumptions about other features being normal and 
abnormal to produce a trained file of a plurality of normality and anomaly scores for each 
of the features. The trained file thus provides an anomaly score for each of the features 
for each of a plurality of different possible abnormalities." These paragraphs further 
provide: "The training process 1 12 [i.e., the process of calculating anomaly scores of said 
features of said normal system operations] can be periodically repeated." This is shown 
in Figure 1. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The issues presented for review by the Board of Patents Appeals and Interferences 
are whether claims 1-26 are unpatentable under 35 U.S.C. §101 on the basis of the 
claimed invention being directed to non-statutory subject matter. 

VII. ARGUMENT 

A. The 35 U.S.C §101 Rejection Claims 1-26 

1. The Position in the Office Action 

The position of the Examiner, as set out in paragraphs 1-14 of the Office Action 
dated April 17, 2007, is quoted below. 

None of the claims is limited to practical applications that indicate a specific 
practical utility for the claimed invention. Examiner finds that In re 'Warmer dam, 
33 F.3d 1354, 31 USPQ2d 1754 (Fed. Cir. 1994) controls the 35 U.S.C. §101 
issues on that point for reasons made clear by the Federal Circuit in AT&T Corp. 
v. Excel Communications, Inc., 50 USPQ2d 1447 (Fed. Cir. 1999). Specifically, 
the Federal Circuit held that the act of: 
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. . .Taking several abstract ideas and manipulating them together adds 
nothing to the basic equation. AT&T v. Excel at 1453 quoting In re 
Warmerdam, 33 F.3d 1354, 1360 (Fed. Cir. 1994). 

Examiner finds that Applicant's "history files" references are just such abstract 

ideas." 

Examiner bases his position upon guidance provided by the Federal Circuit in In 
re Warmerdam, as interpreted by AT&T v. Excel. This set of precedents is within 
the same line of cases as the Alappat-State Street Bank decisions and is in 
complete agreement with those decisions. Warmerdam is consistent with State 
Street's holding that: 

Today we hold that the transformation of data, representing discrete dollar 
amounts, by a machine through a series of mathematical calculations into 
a final share price, constitutes a practical application of a mathematical 
algorithm, formula, or calculation because it produces "a useful, concrete 
and tangible result" - a final share price momentarily fixed for recording 
purposes and even accepted and relied upon by regulatory authorities and 
in subsequent trades, (emphasis added) State Street Bank at 1601. 

True enough, that case later eliminated the "business method exception" in order 
to show that business methods were not per se nonstatutory, but the court clearly 
did no go so far as to make business methods per se statutory. A plain reading of 
the excerpt above shows that the Court was very specific in its definition of the 
new practical application that indicates a specific practical utility for the claimed 
invention. It would have been much easier for the court to say that "business 
methods were per se statutory" than it was to define the practical application in 
the case as ". . .the transformation of data, representing discrete dollar amounts, 
by a machine through a series of mathematical calculations into a final share 
price..." 
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The court was being very specific. 

Additionally, the court was also careful to specify that the "useful, concrete and 
tangible result" it found was "a final share price momentarily fixed for recording 
purposes and even accepted and relied upon by regulatory authorities and in 
subsequent trades ." (i.e. the trading activity is the further practical use of the real 
world monetary data beyond the transformation in the computer - i.e., "post- 
processing activity".) 

Applicant cites no such specific results to define a useful, concrete and tangible 
result. Neither does Applicant specify the associated practical application with 
the kind of specificity the Federal Circuit used. 

Furthermore, in the case In re Warmerdam, the Federal Circuit held that: 

. . . The dispositive issue for assessing compliance with Section 101 in this 
case is whether the claim is for a process that goes beyond simply 
manipulating 'abstract ideas' or 'natural phenomena' . . .As the Supreme 
Court has made clear, "a[n] idea of itself is not patentable, . . . taking 
several abstract ideas and manipulating them together adds nothing to the 
basic equation . In re Warmerdam 31 USPQ2d at 1759 (emphasis added). 

Since the Federal Circuit held in Warmerdam that this is the "dispositive issue" 
when it judged the usefulness, concreteness, and tangibility of the claim 
limitations in that case, Examiner in the present case views this holding as the 
dispositive issue for determining whether a claim is "useful, concrete, and 
tangible" in similar cases. Accordingly, the Examiner finds that Applicant 
manipulated a set of abstract "history files" to solve purely algorithmic problems 
in the abstract (i.e., what kind of "history files" are used? Heart rhythm data? 
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Algebraic equations? Boolean logic problems? Fuzzy logic algorithms? 
Probabilistic word problems? Philosophical ideas? Even vague expressions, about 
which even reasonable persons could differ as to their meaning? Combinations 
thereof?) Clearly, a claim for manipulation of "history files" is provably even 
more abstract (and thereby less limited in practical application) than pure 
"mathematical algorithms" which the Supreme Court has held are per se 
nonstatutory - in fact, it includes the expression of nonstatutory mathematical 
algorithms. 

Since the claims are not limited to exclude such abstractions, the broadest 
reasonable interpretation of the claim limitations includes such abstractions. 
Therefore, the claims are impermissibly abstract under 35 U.S.C. §101 doctrine. 

Since Warmerdam is within the Alappat-State Street Bank line of cases, it takes 
the same view of "useful, concrete, and tangible" the Federal Circuit applied in 
State Street Bank. Therefore, under State Street Bank, this could not be a "useful, 
concrete and tangible result". There is only manipulation of abstract ideas. 

The Federal Circuit validated the use of Warmerdam in its more recent AT&T 
Corp. v. Excel Communications, Inc. decision. The Court reminded us that: 

Finally, the decision in In re Warmerdam, 33 F.3d 1354, 31 USPQ2d 
1754 (Fed. Cir. 1994) is not to the contrary. *** The court found that the 
claimed process did nothing more than manipulate basic mathematical 
constructs and concluded that 'taking several abstract ideas and 
manipulating them together adds nothing to the basic equation'; 
hence, the court held that the claims were properly rejected under § 101 ... 
Whether one agrees with the court's conclusion on the facts, the holding 
of the case is a straightforward application of the basic principle that mere 

18 



Appeal Brief 

laws of nature, natural phenomena, and abstract ideas are not within the 
categories of inventions or discoveries that may be patented under §101 . 
(emphasis added) AT&T Corp. v. Excel Communications, Inc., 50 
USPQ2d 1447, 1453 (Fed. Cir. 1999). 

Remember that in In re Warmerdam, the Court said that this was the dispositive 
issue to be considered. In the AT&T decision cited above, the Court reaffirms that 
his is the issue for assessing the "useful, concrete, and tangible" nature of a set of 
claims under §101 doctrine. Accordingly, Examiner views the Warmerdam 
holding as the dispositive issue in this analogous case. 

The fact that the invention is merely the manipulation of abs tract ideas is clear. 
The data referred to by Applicant's idea of "history files" is simply an abstract 
construct that does not provide limitations in the claims to the transformation of 
real world data (such as monetary data or heart rhythm data) by some disclosed 
process. Consequently, the necessary conclusion under AT&T, State Street and 
Warmerdam, is straightforward and clear. The claims take several abstract ideas 
(i.e., "history files" in the abstract) and manipulate them together adding nothing 
to the basic equation. Claims 1-26 are, thereby, rejected under 35 U.S.C. §101. 

2. The Appellants' Position Regarding The Rejection of Claims 1- 
26 under 35 U.S.C. §101 

The Appellants respectfully, but strongly, disagree with the Examiner's position 
that none of the claims is limited to practical applications that indicate a specific practical 
utility for the claimed invention. 



(a) Appellants' Position Regarding Rejection Of Independent Claims 1 



and 20 
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In rejecting independent claims 1 and 20 under 35U.S.C. §101 for being directed 
to non-statutory subject matter, the Examiner indicated that In re Warmerdam, 33 F.3d 
1354, 31 USPQ2d 1754 (Fed. Cir. 1994), which held that "...Taking several abstract 
ideas and manipulating them together adds nothing to the basic equation", was 
controlling. Specifically, the Examiner determined that the claimed invention did not 
have a useful, concrete and tangible result because the Appellant "manipulated a set of 
abstract 'history files' to solve purely algorithmic problems in the abstract". The 
Examiner further provided that "the fact that the invention is merely the manipulation of 
abstract ideas is clear. The data referred to by Applicant's idea of "history files" is 
simply an abstract construct that does not provide limitations in the claims to the 
transformation of real world data (such as monetary data or heart rhythm data) by some 
disclosed process. Consequently, the necessary conclusion under AT&T, State Street and 
Warmerdam, is straight forward and clear. The claims take several abstract ideas (i.e., 
"history files" in the abstract) and manipulate them together adding nothing to the basic 
equation." The Appellants respectfully disagree. 

Independent claims 1 and 20 each include the claim limitations of "recording 
features of normal system operations in a history file" and "creating a model for each of 
said features of said normal system operations in said history file". These limitations 
imply that during normal system operations features of the system are determined in 
some manner. The features are then recorded (e.g., as historical data) in a history file. 
Then, for each feature in the history file, a model is created. This aspect of the invention 
is explained in detail throughout the disclosure. For example, the Abstract provides that 
the system records actions performed as features in a history file and automatically 
creates a model for each feature. Paragraphs [0006] and [0023] provide that the 
invention begins with historical data maintained in a history file and that a model is 
created for each feature only from normal data in the history file. Paragraph [0020] 
references a dataset of N features from which N models are created. Therefore, the 
Appellants submit that contrary to the Examiner's finding the "history files" are not just 
abstract ideas, but rather contain real world data (i.e., a recording of features of normal 
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system operations) from which models are created (i.e., a model is created for each 
feature of normal system operations that is recorded). 

Furthermore, if, as indicated by the Examiner, the data referred to by the "history 
files" is simply an abstract construct that did not provide limitations in the claims to the 
transformation of real world data by some disclosed process, it was still incumbent upon 
the Examiner to determine whether the method otherwise produces a useful, concrete or 
tangible result. That is, it is generally understood that to establish utility under 35 U.S.C. 
§101 method inventions as a whole must produce a "useful, concrete and tangible result." 
(see State Street, 149 F.3d at 1373-74, 47 USPQ2d at 1601-02). Additionally, AT&T 
Corp v. Excel Communications, Inc. Ill F.3d 1352, 1358-59, 50 USPQ2d 1447, 1452 
(Fed. Cir. 1999) provides that physical transformation "is not an invariable requirement, 
but merely one example, of how a mathematical algorithm [or law of nature] may bring 
about a useful application." If the Examiner determines that there is no physical 
transformation, additional review is required to determine if the claim provides a useful, 
tangible and concrete result. The review by the Examiner should focus not on each step, 
but on whether the final result achieved by the claimed invention is "useful, concrete and 
tangible" (see AT&T 172 F.3d at 1358-5). 

The Appellants submit that the results of the method embodiments disclosed are 
"useful." Specifically, the Appellants submit that a credible, specific, and substantial use 
for the method of the invention (namely identifying and reporting anomalous events that 
occur during system operations) is readily apparent and well-established in the 
independent claims themselves. That is, each of the independent claims provides for a 
method of automatically identifying anomalous situations that occur during system 
operations. The limiting features in each of the claims include, but are not limited to, the 
following: (1) "recording features of normal system operations in a history file;" (2) 
"automatically creating a model for each of said features of said normal system 
operations in said history file;" (3) "calculating anomaly scores of said features of said 
normal system operations and storing said anomaly scores in a trained file;" (4) 
"establishing a threshold to evaluate whether events in live system operations are 
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anomalies as compared to said normal system operations;" (5) "automatically identifying 
anomalous events in said live system operations based on said anomaly scores and on 
said threshold;" (6) "reporting said anomalous events;" and (7) "periodically repeating 
said calculating." Those skilled in the art would immediately appreciate why the 
invention is useful (i.e., would appreciate why it is important to be able to identify when 
anomalous events occur during system operations and to report out the occurrence of 
those anomalous events). 

This credible, specific, and substantial use for the method of the invention 
(namely identifying and reporting anomalous events that occur during live system 
operations) is further asserted in the disclosure at paragraph [0004]. That is, in order to 
achieve a goal of autonomic computing it is important that a target system be able to 
perform self-diagnosis. Per paragraph [0018], the claimed invention provides a general 
solution to conventional problems associated with self-diagnosis by providing a method 
that uses an additive approach to combine evidence from multiple sources (i.e., history 
files) and then uses a probabilitstic thresholding approach to detect anomalies. These 
detected anomalies can be reported to a system user (see paragraph [0063]). Per 
paragraph [0064], the claimed invention is superior to prior art systems because it takes 
advantage of inter-feature correlation and predicts the value of one feature using values 
of other features and because it uses a threshold to predict anomalies. 

Furthermore, the Appellants submit that the results of the method embodiments 
disclosed are also "tangible" and "concrete." Specifically, the claim limitations of 
"identifying anomalous events in said live system operations" and "reporting said 
anomalous events" are beneficial real- world results of performing the method of the 
invention (i.e., they are tangible and not abstract results, see Gottschalk v. Benson, 409 
U.S. 63, 71-72, 175 USPQ 673, 676 (1972)). That is, as system operations occur, the 
method is able to identify anomalous events that occur and to report out those events. 
The process steps are not abstract or theoretical. Additionally, the claim limitations of 
"identifying anomalous events in said live system operations" and "reporting said 
anomalous events" are substantially repeatable (i.e., concrete, see In re Swartz, 232 F.3d 
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862, 864, 56 USPQ2d 1703, 1704 (Fed. Cir. 2000). That is, as the live system operations 
proceed, the method will be able to identify and report out each anomalous event that 
occurs. The identification process is based on the previously calculated anomaly scores 
and previously established threshold. To ensure that the anomalous events will continue 
to be properly identified throughout the live system operations, the claim limitation of 
periodically recalculating the anomaly scores is also included. 

Therefore, independent claims 1 and 20 are directed to statutory subject matter 
under 35 U.S.C. §101. Further, dependent claims 2-7 and 21-26 are similarly patentable, 
not only by virtue of their dependency from a patentable independent claim, but also by 
virtue of the additional features of the invention they define. Moreover, the Appellants 
note that all claims are properly supported in the specification and accompanying 
drawings. In view of the foregoing, the Board is respectfully requested to reconsider and 
withdraw the rejections. 

(b) Appellants' Position Regarding The Rejection of Independent Claim 8 

In rejecting independent claim 8 under 35 U.S.C. § 101 for being directed to non- 
statutory subject matter, the Examiner indicated that In re Warmerdam, 33 F.3d 1354, 31 
USPQ2d 1754 (Fed. Cir. 1994), which held that "...Taking several abstract ideas and 
manipulating them together adds nothing to the basic equation", was controlling. 
Specifically, the Examiner determined that the claimed invention did not have a useful, 
concrete and tangible result because the Appellant "manipulated a set of abstract 'history 
files' to solve purely algorithmic problems in the abstract". The Examiner further 
provided that "the fact that the invention is merely the manipulation of abstract ideas is 
clear. The data referred to by Applicant's idea of "history files" is simply an abstract 
construct that does not provide limitations in the claims to the transformation of real 
world data (such as monetary data or heart rhythm data) by some disclosed process. 
Consequently, the necessary conclusion under At&T, State Street and Warmerdam, is 
straight forward and clear. The claims take several abstract ideas (i.e., "history files" in 
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the abstract) and manipulate them together adding nothing to the basic equation." The 
Appellants respectfully disagree. 

Independent claim 8 includes the claim limitations of "recording features of 
normal system operations in a history file" and "creating a model for each of said features 
of said normal system operations in said history file". These limitations imply that 
during normal system operations features of the system are determined in some manner. 
The features are then recorded (e.g., as historical data) in a history file. Then, for each 
feature in the history file, a model is created. This aspect of the invention is explained in 
detail throughout the disclosure. For example, the Abstract provides that the system 
records actions performed as features in a history file and automatically creates a model 
for each feature. Paragraphs [0006] and [0023] provide that the invention begins with 
historical data maintained in a history file and that a model is created for each feature 
only from normal data in the history file. Paragraph [0020] references a dataset of N 
features from which N models are created. Therefore, the Appellants submit that 
contrary to the Examiner's finding the "history files" are not just abstract ideas, but rather 
contain real world data (i.e., a recording of features of normal system operations) from 
which models are created (i.e., a model is created for each feature of normal system 
operations that is recorded). 

Furthermore, if, as indicated by the Examiner, the data referred to by the "history 
files" is simply an abstract construct that did not provide limitations in the claims to the 
transformation of real world data by some disclosed process, it was still incumbent upon 
the Examiner to determine whether the method otherwise produces a useful, concrete or 
tangible result. That is, it is generally understood that to establish utility under 35 U.S.C. 
§101 method inventions as a whole must produce a "useful, concrete and tangible result." 
(see State Street, 149 F.3d at 1373-74, 47 USPQ2d at 1601-02). Additionally, AT&T 
Corp v. Excel Communications, Inc. 172 F.3d 1352, 1358-59, 50 USPQ2d 1447, 1452 
(Fed. Cir. 1999) provides that physical transformation "is not an invariable requirement, 
but merely one example, of how a mathematical algorithm [or law of nature] may bring 
about a useful application." If the Examiner determines that there is no physical 
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transformation, additional review is required to determine if the claim provides a useful, 
tangible and concrete result. The review by the Examiner should focus not on each step, 
but one whether the final result achieved by the claimed invention is "useful, concrete 
and tangible" (see AT&T 111 F.3d at 1358-59). 

The Appellants submit that the results of the method embodiments disclosed are 
"useful." Specifically, the Appellants submit that a credible, specific, and substantial use 
for the method of the invention (namely identifying and reporting anomalous events that 
occur during system operations) is readily apparent and well-established in the 
independent claims themselves. That is, claim 8 provides for a method of automatically 
identifying anomalous situations that occur during system operations. The limiting 
features in claim 8 include, but are not limited to, the following: (1) "recording features 
of normal system operations in a history file;" (2) "automatically creating a model for 
each of said features of said normal system operations in said history file;" (3) 
"calculating anomaly scores of said features of said normal system operations and storing 
said anomaly scores in a trained file;" (4) "establishing a threshold to evaluate whether 
events in live system operations are anomalies as compared to said normal system 
operations;" (5) "automatically identifying anomalous events in said live system 
operations based on said anomaly scores and on said threshold;" (6) "reporting said 
anomalous events? (7) "periodically repeating said calculating"; and (8) "wherein said 
creating of said model for each of said features comprises: establishing relationships that 
exist between each of said features for said normal system operations; selecting a labeled 
feature from said features; mathematically rearranging said relationships from the point 
of view of said labeled feature to create a solution for said labeled feature, wherein said 
solution comprises a model for said labeled feature; selecting different features as said 
labeled feature and repeating said process of mathematically rearranging said 
relationships to produce solutions from the point of view of each remaining feature as 
models for the remaining features." Those skilled in the art would immediately 
appreciate why the invention is useful (i.e., would appreciate why it is important to be 
able to identify when anomalous events occur during system operations and to report out 
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the occurrence of those anomalous events). 

This credible, specific, and substantial use for the method of the invention 
(namely identifying and reporting anomalous events that occur during live system 
operations) is further asserted in the disclosure at paragraph [0004]. That is, in order to 
achieve a goal of autonomic computing it is important that a target system be able to 
perform self-diagnosis. Per paragraph [0018], the claimed invention provides a general 
solution to conventional problems associated with self-diagnosis by providing a method 
that uses an additive approach to combine evidence from multiple sources (i.e., history 
files) and then uses a probabilistic thresholding approach to detect anomalies. These 
detected anomalies can be reported to a system user (see paragraph [0063]). Per 
paragraph [0064], the claimed invention is superior to prior art systems because it takes 
advantage of inter-feature correlation and predicts the value of one feature using values 
of other features and because it uses a threshold to predict anomalies. 

Furthermore, the Appellants submit that the results of the method embodiments 
disclosed are also "tangible" and "concrete." Specifically, the claim limitations of 
"identifying anomalous events in said live system operations" and "reporting said 
anomalous events" are beneficial real-world results of performing the method of the 
invention (i.e., they are tangible and not abstract results, see Gottschalk v. Benson, 409 
U.S. 63, 71-72, 175 USPQ 673, 676 (1972)). That is, as system operations occur, the 
method is able to identify anomalous events that occur and to report out those events. 
These process steps are not abstract or theoretical. Additionally, the claim limitations of 
"identifying anomalous events in said live system operations" and "reporting said 
anomalous events" are substantially repeatable (i.e., concrete, see In re Swartz, 232 F.3d 
862, 864, 56 USPQ2d 1703, 1704 (Fed. Cir. 2000). That is, as the live system operations 
proceed, the method will be able to identify and report out each anomalous event that 
occurs. The identification process is based on the previously calculated anomaly scores 
and previously established threshold. To ensure that the anomalous events will continue 
to be properly identified throughout the live system operations, the claim limitation of 
periodically recalculating the anomaly scores is also included. 
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Therefore, independent claim 8 is directed to statutory subject matter under 35 
U.S.C. §101. Further, dependent claims 9-14 are similarly patentable, not only by virtue 
of their dependency from a patentable independent claim, but also by virtue of the 
additional features of the invention they define. Moreover, the Appellants note that all 
claims are properly supported in the specification and accompanying drawings. In view 
of the foregoing, the Examiner is respectfully requested to reconsider and withdraw the 
rejections. 

(c) Appellants' Position Regarding The Rejection of Independent Claim 
14 

In rejecting independent claim 14 under 35 U.S.C. §101 for being directed to non- 
statutory subject matter, the Examiner indicated that In re Warmerdam, 33 F.3d 1354, 31 
USPQ2d 1754 (Fed. Cir. 1994), which held that "...Taking several abstract ideas and 
manipulating them together adds nothing to the basic equation", was controlling. 
Specifically, the Examiner determined that the claimed invention did not have a useful, 
concrete and tangible result because the Appellant "manipulated a set of abstract 'history 
files' to solve purely algorithmic problems in the abstract". The Examiner further 
provided that "the fact that the invention is merely the manipulation of abstract ideas is 
clear. The data referred to by Applicant's idea of "history files" is simply an abstract 
construct that does not provide limitations in the claims to the transformation of real 
world data (such as monetary data or heart rhythm data) by some disclosed process. 
Consequently, the necessary conclusion under AT&T, State Street and Warmerdam, is 
straight forward and clear. The claims take several abstract ideas (i.e., "history files" in 
the abstract) and manipulate them together adding nothing to the basic equation." The 
Appellants respectfully disagree. 

Independent claim 14 includes the claim limitations of "recording features of 
normal system operations in a history file" and "creating a model for each of said features 
of said normal system operations in said history file". These limitations imply that 
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during normal system operations features of the system are determined in some manner. 
The features are then recorded (e.g., as historical data) in a history file. Then, for each 
feature in the history file, a model is created. This aspect of the invention is explained in 
detail throughout the disclosure. For example, the Abstract provides that the system 
records actions performed as features in a history file and automatically creates a model 
for each feature. Paragraphs [0006] and [0023] provide that the invention begins with 
historical data maintained in a history file and that a model is created for each feature 
only from normal data in the history file. Paragraph [0020] references a dataset of N 
features from which N models are created. Therefore, the Appellants submit that 
contrary to the Examiner's finding the "history files" are not just abstract ideas, but rather 
contain real world data (i.e., a recording of features of normal system operations) from 
which models are created (i.e., a model is created for each feature of normal system 
operations that is recorded). 

Furthermore, if, as indicated by the Examiner, the data referred to by the "history 
files" is simply an abstract construct that did not provide limitations in the claims to the 
transformation of real world data by some disclosed process, it was still incumbent upon 
the Examiner to determine whether the method otherwise produces a useful, concrete or 
tangible result. That is, it is generally understood that to establish utility under 35 U.S.C. 
§101 method inventions as a whole must produce a "useful, concrete and tangible result." 
(see State Street, 149 F.3d at 1373-74, 47 USPQ2d at 1601-02). Additionally, AT&T 
Corp v. Excel Communications, Inc. 172 F.3d 1352, 1358-59, 50 USPQ2d 1447, 1452 
(Fed. Cir. 1999) provides that physical transformation "is not an invariable requirement, 
but merely one example, of how a mathematical algorithm [or law of nature] may bring 
about a useful application." If the Examiner determines that there is no physical 
transformation, additional review is required to determine if the claim provides a useful, 
tangible and concrete result. The review by the Examiner should focus not on each step, 
but on whether the final result achieved by the claimed invention is "useful, concrete and 
tangible" (see AT&T 172 F.3d at 1358-59). 

The Appellants submit that the results of the method embodiments disclosed are 
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"useful." Specifically, the Appellants submit that a credible, specific, and substantial use 
for the method of the invention (namely identifying and reporting anomalous events that 
occur during system operations) is readily apparent and well-established in the 
independent claims themselves. That is, each of the independent claims provides for a 
method of automatically identifying anomalous situations that occur during system 
operations. The claim limitations in claim 14 include, but are not limited to, the 
following: (1) "recording features of normal system operations in a history file;" (2) 
"automatically creating a model for each of said features of said normal system 
operations in said history file;" (3) "calculating anomaly scores of said features of said 
normal system operations and storing said anomaly scores in a trained file;" (4) 
"establishing a threshold to evaluate whether events in live system operations are 
anomalies as compared to said normal system operations;" (5) "automatically identifying 
anomalous events in said live system operations based on said anomaly scores and on 
said threshold;" (6) "reporting said anomalous events? (7) "periodically repeating said 
calculating"; and (8) "wherein said calculating comprises: predicting a likelihood that 
each feature will be normal when one or more of the other features are abnormal, using 
said model of each of said features; repeating said predicting using different 
presumptions about other features being normal and abnormal to produce said trained file 
of a plurality of anomaly scores for each of said features." Those skilled in the art would 
immediately appreciate why the invention is useful (i.e., would appreciate why it is 
important to be able to identify when anomalous events occur during system operations 
and to report out the occurrence of those anomalous events). 

This credible, specific, and substantial use for the method of the invention 
(namely identifying and reporting anomalous events that occur during live system 
operations) is further asserted in the disclosure at paragraph [0004]. That is, in order to 
achieve a goal of autonomic computing it is important that a target system be able to 
perform self-diagnosis. Per paragraph [0018], the claimed invention provides a general 
solution to conventional problems associated with self-diagnosis by providing a method 
that uses an additive approach to combine evidence from multiple sources (i.e., history 
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files) and then uses a probabilitstic thresholding approach to detect anomalies. These 
detected anomalies can be reported to a system user (see paragraph [0063]). Per 
paragraph [0064], the claimed invention is superior to prior art systems because it takes 
advantage of inter-feature correlation and predicts the value of one feature using values 
of other features and because it uses a threshold to predict anomalies. 

Furthermore, the Appellants submit that the results of the method embodiments 
disclosed are also "tangible" and "concrete." Specifically, the claim limitations of 
"identifying anomalous events in said live system operations" and "reporting said 
anomalous events" are beneficial real-world results of performing the method of the 
invention (i.e., they are tangible and not abstract results, see Gottschalk v. Benson, 409 
U.S. 63, 71-72, 175 USPQ 673, 676 (1972)). That is, as system operations occur, the 
method is able to identify anomalous events that occur and to report out those events. 
These claim limitations are neither abstract nor theoretical. Additionally, the claim 
limitations of "identifying anomalous events in said live system operations" and 
"reporting said anomalous events" are substantially repeatable (i.e., concrete, see In re 
Swartz, 232 F.3d 862, 864, 56 USPQ2d 1703, 1704 (Fed. Cir. 2000). That is, as the live 
system operations proceed, the method will be able to identify and report out each 
anomalous event that occurs. The identification process is based on the previously 
calculated anomaly scores and previously established threshold. To ensure that the 
anomalous events will continue to be properly identified throughout the live system 
operations, the claim limitation of periodically recalculating the anomaly scores is also 
included. 

Therefore, independent claim 14 is directed to statutory subject matter under 35 
U.S.C. §101. Further, dependent claims 15-19 are similarly patentable, not only by virtue 
of their dependency from a patentable independent claim, but also by virtue of the 
additional features of the invention they define. Moreover, the Appellants note that all 
claims are properly supported in the specification and accompanying drawings. In view 
of the foregoing, the Examiner is respectfully requested to reconsider and withdraw the 
rejections. 
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B. The 35 U.S.C §112 Rejection Claims 1-26 

1. The Position in the Office Action 

The position of the Examiner, as set out in paragraphs 1-14 of the Office Action 
dated April 17, 2007 is quoted below. 

Claims 1-26 are rejected under 35 U.S.C. § 1 12, first paragraph because the 
current case law (and accordingly, the MPEP) require such a rejection if a §101 
rejection is given because when Applicant has not in fact disclosed the practical 
application for the invention, as a matter of law there is no way Applicant could 
have disclosed how to practice the undisclosed practically application. 

2. The Appellants' Position Regarding Claims 1, 8, 14, and 20 
under 35 U.S.C. §112 

Given the Appellants position that claims 1-26 are directed to statutory subject 
matter under 35 U.S.C. §101 (see above discussion in section VII A.2) and further given 
the fact that the only basis for the rejection of claims 1-26 under 35 U.S.C. §112 is the 
existence of the rejection of those claims under 35 U.S.C §101 rejections, the Board is 
respectfully requested to reconsider and withdraw the rejections. 

VIII. CONCLUSION 

In view of the foregoing, the Appellants respectfully submit that independent 
claims 1, 8, 14, and 20, and dependent claims 2-7, 9-13, 15-19, and 21-26 are similarly 
patentable, not only by virtue of their dependency from patentable independent claims, 
respectively, but also by virtue of the additional features of the Appellants' claimed 
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invention they define. Thus, the Appellants respectfully request that the Board reconsider 
and withdraw the rejections of claims 1-26 and pass these claims to issue. 

Please charge any deficiencies and credit any overpayments to Attorney's Deposit 
Account Number 50-0510. 

Respectfully submitted, 



Date: May 24, 2007 /Pamela M. Riley/ 

Pamela M. Riley, Esq. 
Registration No. 40,146 

Gibb & Rahman, LLC 
2568-A Riva Road, Suite 304 
Annapolis, MD, 21401 
Voice: (301) 261-8625 
Fax: (301) 261-8825 
Customer No. 29154 
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IX. CLAIMS APPENDIX 

1. A method of automatically identifying anomalous situations during system 
operations, said method comprising: 

recording features of normal system operations in a history file; 

automatically creating a model for each of said features of said normal system 
operations in said history file; 

calculating anomaly scores of said features of said normal system operations and 
storing said anomaly scores in a trained file; 

establishing a threshold to evaluate whether events in live system operations are 
anomalies as compared to said normal system operations; 

automatically identifying anomalous events in said live system operations based 
on said anomaly scores and on said threshold; 

reporting said anomalous events; and 

periodically repeating said calculating. 

2. The method in claim 1, wherein said creating comprises: 

establishing relationships that exist between each of said features of said normal 
system operations; 

selecting a labeled feature from said features; 

mathematically rearranging said relationships from the point of view of said 
labeled feature to create a solution for said labeled feature, wherein said solution 
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comprises a model for said labeled feature; 

selecting different features as said labeled feature and repeating said process of 
mathematically rearranging said relationships to produce solutions from the point of view 
of each remaining feature as models for the remaining features. 

3. The method in claim 2, wherein said solution comprises a mathematical statement 
of what said labeled feature equals in terms of the relationships between the remaining 
features. 

4. The method in claim 2, wherein said normal system operations comprise said 
features in said history file at the time said models are created. 

5. The method in claim 1, wherein said calculating comprises: 

predicting a likelihood that said each feature will be normal when one or more of 
the other features are abnormal, using said model of each of said features; 

repeating said predicting using different presumptions about other features being 
normal and abnormal to produce said trained file of a plurality of anomaly scores for each 
of said features. 

6. The method in claim 5, wherein said trained file provides an normally score for 
each of said features for each of a plurality of different possible abnormalities. 
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7. The method in claim 5, wherein said automatically identifying comprises: 
determining values of features for a given operation of said system; 

referring to said trained file to retrieve an anomaly score for each of said features 
of said given operation; 

comparing said anomaly score for each of said features of said given operation 
with said threshold to determine whether each anomaly score exceeds said threshold. 

8. A method of automatically identifying anomalous situations during system 
operations, said method comprising: 

recording features of normal system operations in a history file; 

automatically creating a model for each of said features of said normal system 
operations in said history file; 

calculating anomaly scores of said features of said normal system operations and 
storing said anomaly scores in a trained file; 

establishing a threshold to evaluate whether events in live system operations are 
anomalies as compared to said normal system operations; 

automatically identifying anomalous events in said live system operations based 
on said anomaly scores and on said threshold; 

reporting said anomalous event; and 

periodically repeating said calculating; 

wherein said creating of said model for each of said features comprises: 

establishing relationships that exist between each of said features for said 
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normal system operations; 

selecting a labeled feature from said features; 

mathematically rearranging said relationships from the point of view of 
said labeled feature to create a solution for said labeled feature, wherein said solution 
comprises a model for said labeled feature; 

selecting different features as said labeled feature and repeating said 
process of mathematically rearranging said relationships to produce solutions from the 
point of view of each remaining feature as models for the remaining features. 

9. The method in claim 8, wherein said solution comprises a mathematical statement 
of what said labeled feature equals in terms of the relationships between the remaining 
features. 

10. The method in claim 8, wherein said normal system operations comprise said 
features in said history file at the time said models are created. 

11. The method in claim 8, wherein said calculating comprises: 

predicting a likelihood that each feature will be normal when one or more of the 
other features are abnormal, using said model of each of said features; 

repeating said predicting using different presumptions about other features being 
normal and abnormal to produce said trained file of a plurality of anomaly scores for each 
of said features. 
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12. The method in claim 11, wherein said trained file provides an normally score for 
each of said features for each of a plurality of different possible abnormalities. 

13. The method in claim 11, wherein said automatically identifying comprises: 
determining values of features for a given operation of said system; 

referring to said trained file to retrieve an anomaly score for each of said features 
of said given operation; 

comparing said anomaly score for each of said features of said given operation 
with said threshold to determine whether each anomaly score exceeds said threshold. 

14. A method of automatically identifying anomalous situations during system 
operations, said method comprising: 

recording features of normal system operations in a history file; 

automatically creating a model for each of said features of said normal system 
operations in said history file; 

calculating anomaly scores of said features of said normal system operations and 
storing said anomaly scores in a trained file; 

establishing a threshold to evaluate whether events in live system operations are 
anomalies as compared to said normal system operations; 

automatically identifying anomalous events in said system operations based on 
said anomaly scores and on said threshold; 
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reporting said anomalous events; and 
periodically repeating said calculating; 
wherein said calculating comprises: 

predicting a likelihood that each feature will be normal when one or more 
of the other features are abnormal, using said model of each of said features; 

repeating said predicting using different presumptions about other features 
being normal and abnormal to produce said trained file of a plurality of anomaly scores 
for each of said features. 

15. The method in claim 14, wherein said creating comprises: 

establishing relationships that exist between each of said features for said normal 
system operations; 

selecting a labeled feature from said features; 

mathematically rearranging said relationships from the point of view of said 
labeled feature to create a solution for said labeled feature, wherein said solution 
comprises a model for said labeled feature; 

selecting different features as said labeled feature and repeating said process of 
mathematically rearranging said relationships to produce solutions from the point of view 
of each remaining feature as models for the remaining features. 

16. The method in claim 15, wherein said solution comprises a mathematical 
statement of what said labeled feature equals in terms of the relationships between the 
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remaining features. 

17. The method in claim 15, wherein said normal system operations comprise said 
features in said history file at the time said models are created. 

18. The method in claim 14, wherein said trained file provides a normally score for 
each of said features for each of a plurality of different possible abnormalities. 

19. The method in claim 14. wherein said automatically identifying comprises: 
determining values of features for a given operation of said system; 

referring to said trained file to retrieve an anomaly score for each of said features 
of said given operation; 

comparing said anomaly score for each of said features of said given operation 
with said threshold to determine whether each anomaly score exceeds said threshold. 

20. A program storage device readable by machine, tangibly embodying a program of 
instructions executable by the machine to perform a method of automatically identifying 
anomalous situations during system operations, said method comprising: 

recording features of normal system operations in a history file; 
automatically creating a model for said each of said features of said normal 
system operations in said history file; 

calculating anomaly scores of said features of said normal system operations and 
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storing said anomaly scores in a file; 

establishing a threshold to evaluate whether events in live system operations are 
anomalies as compared to said normal system operations; 

automatically identifying anomalous events in said live system operations based 
on said anomaly scores and on said threshold; 

reporting said anomalous events; and 

periodically repeating said calculating. 

21. The program storage device in claim 20, wherein creating comprises: 
establishing relationships that exist between each of said features for said normal 

system operations; 

selecting a labeled feature from said features; 

mathematically rearranging said relationships from the point of view of said 
labeled feature to create a solution for said labeled feature, wherein said solution 
comprises a model for said labeled feature; 

selecting different features as said labeled feature and repeating said process of 
mathematically rearranging said relationships to produce solutions from the point of view 
of each remaining feature as models for the remaining features. 

22. The program storage device in claim 21, wherein said method further comprises a 
mathematical statement of what said labeled feature equals in terms of the relationships 
between the remaining features. 
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23. The program storage device in claim 21, wherein said normal system operations 
comprise said features in said history file at the time said models are created. 

24. The program storage device in claim 20, wherein said calculating further 
comprises: 

predicting a likelihood that each feature will be normal when one or more of the 
other features are abnormal, using said model of each of said features; 

repeating said predicting using different presumptions about other features being 
normal and abnormal to produce said trained file of a plurality of anomaly scores for each 
of said features. 

25. The program storage device in claim 24, wherein said trained file provides an 
normally score for each of said features for each of a plurality of different possible 
abnormalities. 

26. The program storage device in claim 24, wherein said automatically identifying 
comprises: 

determining values of features for a given operation of said system; 
referring to said trained file to retrieve an anomaly score for each of said features 
of said given operation; 

comparing said anomaly score for each of said features of said given operation 
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with said threshold to determine whether each anomaly score exceeds said threshold. 
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X. EVIDENCE APPENDIX 

There is no other evidence known to Appellants, Appellants' legal representative 
or Assignee which would directly affect or be directly affected by or have a bearing on 
the Board's decision in this appeal. 
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XI. RELATED PROCEEDINGS APPENDIX 

There is no other related proceedings known to Appellants, Appellants' legal 
representative or Assignee which would directly affect or be directly affected by or have 
a bearing on the Board's decision in this appeal. 
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